Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes to speed up qvm-ls #36

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

qubesuser
Copy link
Contributor

This is the client part of a bunch of changes that get qvm-ls to around 200ms run time.

Warning: I haven't tested them much, and they change fundamental code, so they probably need fixes.

In particular, all properties are now cached by default, so anything that expects to see changes is now broken and needs to be fixed.

This makes use of the new APIs introduced in QubesOS/qubes-core-admin#165, and also contains a bunch of optimizations of the Python code.

This makes it get all the data with a single qubesd call.
If qubesd returns a label name, we can just assume it's valid.

This makes qvm-ls take only one qubesd call.
Tools should be written to be fast enough that spinners don't become necessary.
vm_state = vm_list_info[0].strip().partition('state=')[2].split(' ')[0]
return vm_state

if not self._state or force:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ouch, this will break all the long-running processes using vm.is_running() or such. One example is qvm-shutdown --wait. IMO caching of VM state should be opt-in, not opt-out.

Copy link
Member

@marmarek marmarek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't reviewed all of this properly. Will do when we agree on the final backend side shape. But at least separate GetAll from GetAllData support - currently parts of the latter are in commit related to the former.

except qubesadmin.exc.QubesDaemonNoResponseError:
raise qubesadmin.exc.QubesPropertyAccessError(key)

self._set_item(key, value, False)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fragile. Especially for long-living processes - anyone else can modify value in the meantime. But also any extension is free to modify value in event handler, including event caused by this very property set.
So, if do this at all, at least make sure the application also receive events. Or at least have it opt-in (and explicitly enable, only in short-lived processes, like some qvm-* tools).

hideseq = '\n'

self.stream.write(hideseq)
self.stream.flush()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@woju will be sad ;)

@marmarek
Copy link
Member

marmarek commented Dec 5, 2017

I've cherry-picked two more commits from this:

  • don't lookup list of labels just to read VM properties 6eb828f
  • don't use ast.literal_eval, just directly convert to the desired type 10c4c2f

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants